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STATUS OF THIS MEMO 


This memo specifies the extensions required of a host implementation 
of the Internet Protocol (IP) to support internetwork multicasting. 
This specification supersedes that given in RFC-966, and constitutes 
a proposed protocol standard for IP multicasting in the 
ARPA-Internet. The reader is directed to RFC-966 for a discussion of 
the motivation and rationale behind the multicasting extension 
specified here. Distribution of this memo is unlimited. 


INTRODUCTION 


IP multicasting is defined as the transmission of an IP datagram to a 
"host group", a set of zero or more hosts identified by a single IP 
destination address. A multicast datagram is delivered to all 
members of its destination host group with the same "best-efforts" 
reliability as regular unicast IP datagrams, i.e. the datagram is not 
guaranteed to arrive at all members of the destination group or in 
the same order relative to other datagrams. 


The membership of a host group is dynamic; that is, hosts may join 
and leave groups at any time. There is no restriction on the 
location or number of members in a host group, but membership in a 
group may be restricted to only those hosts possessing a private 
access key. A host may be a member of more than one group at a time. 
A host need not be a member of a group to send datagrams to it. 


A host group may be permanent or transient. A permanent group has a 
well-known, administratively assigned IP address. It is the address, 
not the membership of the group, that is permanent; at any time a 
permanent group may have any number of members, even zero. A 
transient group, on the other hand, is assigned an address 
dynamically when the group is created, at the request of a host. A 
transient group ceases to exist, and its address becomes eligible for 
reassignment, when its membership drops to zero. 


The creation of transient groups and the maintenance of group 
membership information is the responsibility of "multicast agents", 
entities that reside in internet gateways or other special-purpose 
hosts. There is at least one multicast agent directly attached to 
every IP network or subnetwork that supports IP multicasting. A host 
requests the creation of new groups, and joins or leaves existing 
groups, by exchanging messages with a neighboring agent. 
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Multicast agents are also responsible for internetwork delivery of 
multicast IP datagrams. When sending a multicast IP datagram, a host 
transmits it to a local network multicast address which identifies 
all neighboring members of the destination host group. If the group 
has members on other networks, a multicast agent becomes an 
additional recipient of the local multicast and relays the datagram 
to agents on each of those other networks, via the internet gateway 
system. Finally, the agents on the other networks each transmit the 
datagram as a local multicast to their own neighboring members of the 
destination group. 


This memo specifies the extensions required of a host IP 
implementation to support IP multicasting, where a "host" is any 
internet host or gateway other than those serving as multicast 
agents. The algorithms and protocols used within and between 
multicast agents are transparent to non-agent hosts and will be 
specified in a separate document. This memo also does not specify 
how local network multicasting is accomplished for all types of 
network, although it does specify the required service interface to 
an arbitrary local network and gives an Ethernet specification as an 
example. Specifications for other types of network will be the 
subject of future memos. 


3. LEVELS OF CONFORMANCE 
There are three levels of conformance to this specification: 
Level 0: no support for IP multicasting. 


There is, at this time, no requirement that all IP implementations 
support IP multicasting. Level 0 hosts will, in general, be 
unaffected by multicast activity. The only exception arises on 
some types of local network, where the presence of level 1 or 2 
hosts may cause misdelivery of multicast IP datagrams to level 0 
hosts. Such datagrams can easily be identified by the presence of 
a class D IP address in their destination address field; they 
should be quietly discarded by hosts that do not support IP 
multicasting. Class D addresses are defined in section 4 of this 
memo. 
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Level 1: support for sending but not receiving multicast IP 
datagrams. 


Level 1 allows a host to partake of some multicast-based services, 
such as resource location or status reporting, but it does not 
allow a host to create or join any host groups. An IP 
implementation may be upgraded from level 0 to level 1 very easily 
and with little new code. Only sections 4, 5, and 6 of this memo 
are applicable to level 1 implementations. 


Level 2: full support for IP multicasting. 


Level 2 allows a host to create, join and leave host groups, as 
well as send IP datagrams to host groups. It requires 
implementation of the Internet Group Management Protocol (IGMP) 
and extension of the IP and local network service interfaces 
within the host. All of the following sections of this memo are 
applicable to level 2 implementations. 


4. HOST GROUP ADDRESSES 


Host groups are identified by class D IP addresses, i.e. those with 
"1110" as their high-order four bits. The remaining 28 bits are 
unstructured as far as hosts are concerned. The addresses of 
well-known, permanent groups are to be published in "Assigned 
Numbers". Class E IP addresses, i.e. those with "1111" as their 
high-order four bits, are reserved for future addressing modes. 


Appendix II contains some background discussion of several issues 
related to host group addresses. 
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I3 


MODEL OF A HOST IP IMPLEMENTATION 


The multicast extensions to a host IP implementation are specified in 
terms of the layered model illustrated below. In this model, ICMP 
and (for level 2 hosts) IGMP are considered to be implemented within 
the IP module, and the mapping of IP addresses to local network 
addresses is considered to be the responsibility of local network 
modules. This model is for expository purposes only, and should not 
be construed as constraining an actual implementation. 


| Upper-Layer Protocol Modules 


| ICMP | IGMP 
IP | | 
Module 


Te o E Local Network Service Interface ----------------- 


Local | IP-to-local address mapping 
Network | 
Modules | 


(e.g. Ethernet) 


| 
| 
(e.g. ARP) | 
| 
| 
| 


To support level 2 IP multicasting, a host IP implementation must 
provide three new services: (1) sending multicast IP datagrams, (2) 
receiving multicast IP datagrams, and (3) managing group membership. 
Only the first service need be provided in level 1 hosts. Each of 
these services is described in a separate section, below. For each 
service, extensions are specified for the IP service interface, the 
IP module, the local network service interface, and an Ethernet local 
network module. Extensions to local network modules other than 
Ethernet are mentioned briefly, but are not specified in detail. 
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6. SENDING MULTICAST IP DATAGRAMS 
6.1. Extensions to the IP Service Interface 


No change to the IP service interface is required to support the 
sending of multicast IP datagrams. An upper-layer protocol module 
merely specifies an IP host group destination, rather than an 
individual IP destination, when it invokes the existing "Send IP" 
operation. 


6.2. Extensions to the IP Module 


To support the sending of multicast IP datagrams, the IP module 
must be extended to recognize IP host group addresses when routing 
outgoing datagrams. Most IP implementations include the following 
logic: 


if IP-destination is on the same local network, 
send datagram locally to IP-destination 
else 
send datagram locally to GatewayTo (IP-destination) 


To allow multicast transmissions, the routing logic must be 
changed to: 


if IP-destination is on the same local network 
or IP-destination is a host group, 
send datagram locally to IP-destination 
else 
send datagram locally to GatewayTo (IP-destination) 


If the sending host is itself a member of the destination group, a 
copy of the outgoing datagram must be looped-back for local 
delivery if and only if loopback was requested when the host 
joined the group (see section 8.1). (This issue does not arise in 
level 1 implementations.) 


On hosts attached to more than one network, each multicast IP 
datagram must be transmitted via one network interface only, 
leaving it to the multicast agents to effect delivery to any other 
required networks. 


A host group address should not be placed in the source address 
field of an outgoing IP datagram. A host group address may be 


used in a source routing option as the last element only. 


It should be noted that a small IP time-to-live (TTL) value can 
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prevent delivery to some members of a destination group. Thus, a 


large TTL value should be used to reach all members. Conversely, 
a small TTL value can be used to advantage to reach only "nearby" 
members of a widely-dispersed group. In clusters of low-delay 


local area networks, the TTL field acts as a hop limit; thus, one 
can perform expanding-ring searches by starting with a TTL of 1 
and incrementing on each retransmission, up to some limit defined 
by the diameter of the cluster. 


6.3. Extensions to the Local Network Service Interface 


No change to the local network service interface is required to 
support the sending of multicast IP datagrams. The IP module 
merely specifies an IP host group destination, rather than an 
individual IP destination, when it invokes the existing "Send 
Local" operation. 


6.4. Extensions to an Ethernet Local Network Module 


The Ethernet directly supports the sending of local multicast 
packets by allowing multicast addresses in the destination field 
of Ethernet packets. All that is needed to support the sending of 
multicast IP datagrams is a procedure for mapping IP host group 
addresses to Ethernet multicast addresses. 


An IP host group address is mapped to an Ethernet multicast 
address by placing the low-order 28-bits of the IP address into 
the low-order 28 bits of an Ethernet address. The high-order 20 
bits of the Ethernet address are set to a well-known value, to be 
published in "Assigned Numbers". 


[At time of publication of this memo, a block of Ethernet 
multicast addresses with 28 unspecified bits had not yet been 
obtained from the allocating authority. If such a block of 
addresses cannot be obtained, an alternative mapping scheme will 
be specified. ] 


6.5. Extensions to Local Network Modules other than Ethernet 


Other networks that directly support multicasting, such as rings 
or buses conforming to the IEEE 802.2 standard, can be handled the 
same way as Ethernet for the purpose of sending multicast IP 
datagrams. For a network that supports broadcast but not 
multicast, such as the Experimental Ethernet, all IP host group 
addresses can be mapped to a single local broadcast address (at 
the cost of increased overhead on all local hosts). Fora 
point-to-point networks like the ARPANET or a public data network 
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(X.25), all IP host group addresses might be mapped to the 
well-known local address of an IP multicast agent; an agent on 
such a network would take responsibility for completing multicast 
delivery within the network as well as among networks. 


7. RECEIVING MULTICAST IP DATAGRAMS 


7.1. Extensions to the IP Service Interface 


No change to the IP service interface is required to support the 
reception of multicast IP datagrams. Incoming multicast IP 
datagrams are delivered to upper-layer protocol modules using the 
same "Receive IP" operation as normal, unicast datagrams. 


7.2. Extensions to the IP Module 


To support the reception of multicast IP datagrams, the IP module 
must be extended to recognize the addresses of IP host groups to 
which the host currently belongs, in addition to the host’s 
individual IP address(es). An incoming datagram destined to one 
of those group addresses is processed exactly the same way as 
datagrams destined to one of the host’s individual addresses. 
Incoming datagrams destined to groups to which the host does not 
belong are discarded without generating any error report. 


On hosts attached to more than one network, if a datagram arrives 
via one network interface, destined for a group to which the host 
belongs only on a different interface, the datagram is quietly 
discarded. (This should occur only as a result of inadequate 
multicast address filtering in the local network module.) 


An incoming datagram is not rejected for having an IP host group 
address in its source address field or anywhere in a source 
routing option. 


An ICMP error message (Destination Unreachable, Time Exceeded, 
Parameter Problem, Source Quench, or Redirect) is never generated 
in response to a datagram destined to an IP host group. 


7.3. Extensions to the Local Network Service Interface 


No change to the local network service interface is required to 
support the reception of multicast IP datagrams. Incoming local 
network packets, whether multicast or unicast, are delivered to 
the IP module using the same "Receive Local" operation. 
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7.4. Extensions to an Ethernet Local Network Module 


To support the reception of multicast IP datagrams, an Ethernet 
module must be able to receive packets addressed to the Ethernet 
multicast addresses that correspond to the host’s IP host group 
addresses. It is highly desirable to take advantage of any 
address filtering capabilities that the Ethernet hardware 
interface may have, so that the host only receives packets that 
are destined to it. 


Unfortunately, many current Ethernet interfaces have a small limit 
on the number of addresses that the hardware can be configured to 
recognize. However, an implementation must be capable of 
listening on an arbitrary number of Ethernet multicast addresses, 
which may mean "opening up" the address filter to accept all 
multicast packets during those periods when the number of 
addresses exceeds the limit of the filter. 


For interfaces with inadequate hardware address filtering, it may 
be desirable (for performance reasons) to perform Ethernet address 
filtering within the software of the Ethernet module. This is not 
mandatory, however, because the IP module performs its own 
filtering based on IP destination addresses. 


7.5. Extensions to Local Network Modules other than Ethernet 


Other multicast networks, such as IEEE 802.2 networks, can be 
handled the same way as Ethernet for the purpose of receiving 
multicast IP datagrams. For pure broadcast networks, such as the 
Experimental Ethernet, all incoming broadcast packets can be 
accepted and passed to the IP module for IP-level filtering. Ona 
point-to-point network, multicast IP datagrams will arrive as 
local network unicasts, so no change to the local network module 
should be necessary. 
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8. MANAGING GROUP MEMBERSHIP 
8.1. Extensions to the IP Service Interface 


To allow upper-layer protocol modules to request that their host 
create, join, or leave a host group, the IP service interface must 
be extended to offer the following three new operations: 


CreateGroup ( private, loopback ) 
--> outcome, group-address, access-—key 


The CreateGroup operation requests the creation of a new, 
transient host group, with this host as its only member. The 
"private" argument specifies if the group is to be private or 
public. The "loopback" argument specifies whether or not 
datagrams sent from this host to the group should be delivered 
locally as well as to other member hosts. The "outcome" result 
indicates whether the request is granted or denied. If it is 
granted, a new 32-bit IP host group address is returned, along 
with a 64-bit access key which is zero for public groups and 
non-zero for private groups. The request may be denied due to 
lack of response from a multicast agent, or lack of resources. 


JoinGroup ( group-address, access-key, loopback ) --> outcome 


The JoinGroup operation requests that this host become a member of 
the host group identified by "group-address", with the specified 
access key. The "loopback" argument specifies whether or not 
datagrams sent from this host to the group should be delivered 
locally as well as to other member hosts. The "outcome" result 
indicates whether the request is granted or denied. The request 
may be denied due to lack of response from a multicast agent, lack 
of resources, an invalid group address, an incorrect access key, 
or already being a member. 


LeaveGroup ( group-address, access-key ) --> outcome 


The LeaveGroup operation requests that this host give up its 
membership in the host group identified by "group-address", with 
the specified access key. The "outcome" result indicates whether 
the request is granted or denied. The request may be denied due 
to an invalid group address, an incorrect access key, or not 
currently being a member. 


Each of these operations may take up to a minute or more to 
complete, depending on the number of IGMP retransmissions 
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performed within the IP module, and time required for a multicast 
agent to generate a reply. However, typical delays should be on 
the order of a few seconds. 


Besides the LeaveGroup operation, a host loses its membership in a 
group whenever the host or its IP module crashes, or, in rare 
circumstances, when a multicast agent revokes its membership. The 
IP service interface should provide some means of informing an 
upper-layer module when its membership has been revoked. 
Membership may be revoked due to lack of resources, deallocation 
of the group address, or the discovery of another host group using 
the same group address with a different access key. (See Appendix 
II for discussion of address recycling issues.) 


It is important to observe that IP group membership is per-host, 
rather than per-process. An IP service interface should not allow 
multiple processes to invoke JoinGroup operations for the same 
group as a way of achieving delivery to more than process. The IP 
module delivers each incoming datagram, whether multicast or 
unicast, to the single upper-layer protocol module identified by 
the protocol field in the datagram’s IP header; it is an 
upper-layer issue whether or not to deliver incoming datagrams to 
more than one process, perhaps using the concept of "process 
groups" or "shared ports". 


8.2. Extensions to the IP Module 


Within the IP module, the membership management operations are 
supported by the Internet Group Management Protocol (IGMP), 
specified in Appendix I. As well as having messages corresponding 
to each of the operations specified above, IGMP also specifies a 
"deadman timer" procedure whereby hosts periodically confirm their 
memberships with the multicast agents. 


The IP module must maintain a data structure listing the IP 
addresses of all host groups to which the host currently belongs, 
along with each group’s loopback policy, access key, and timer 
variables. This data structure is used by the IP multicast 
transmission service to know which outgoing datagrams to loop 
back, and by the reception service to know which incoming 
datagrams to accept. The purpose of IGMP and the management 
interface operations is to maintain this data structure. 


On hosts attached to more than one network, each membership is 
associated with a particular network interface. On such a host 
the management interface operations above may each require an 
additional parameter specifying to which interface the create, 
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join, or leave request applies. The group membership data 
structure must also be extended to associate an interface with 
each membership. If a host joins the same host group on more than 
one network interface, it can expect to receive multiple copies of 
each datagram sent to that group. 


8.3. Extensions to the Local Network Service Interface 


To allow an IP module to control what packets should be accepted 
by the local network module, it is necessary to extend the local 
network service interface with the following two new operations: 


AcceptAddress ( group-address ) 
RejectAddress ( group-address ) 


where "group-address" is an IP host group address. The 
AcceptAddress operation requests the local network module to 
accept and deliver up subsequently arriving packets destined to 
the local network address corresponding to "group-address". The 
RejectAddress operation requests the local network module to stop 
delivering up packets destined to the local network address 
corresponding to "group-address". 


Any local network module is free to ignore RejectAddress requests, 
and may deliver up packets destined to more addresses than just 
those specified in AcceptAddress requests, if it is unable to 
filter incoming packets adequately. 


8.4. Extensions to an Ethernet Local Network Module 


An Ethernet module responds to AcceptAddress operations by adding 
the corresponding Ethernet multicast address to its acceptance 
filter for incoming packets. A RejectAddress operation causes the 
corresponding Ethernet address to be dropped from the filter. For 
Ethernet interfaces with a limit on the number of addresses that 
can be added to the filter, the Ethernet software module must 
detect when that threshold is exceeded and open up the filter to 
accept all multicast packets. It should also detect when the 
number of addresses drops below the threshold and revert to 
individual address filtering. 


8.5. Extensions to Local Network Modules other than Ethernet 


Other multicast networks, such as IEEE 802.2 networks, can be 
handled the same way as Ethernet for the purpose of controlling 
address filtering. For a pure broadcast network or a 
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point-to-point network, the AcceptAddress and RejectAddress 
operations may have no effect; all incoming packets could be 
passed to the IP module for IP-level filtering. 
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APPENDIX I. 


The Internet Group Management Protocol 


INTERNET GROUP MANAGEMENT PROTOCOL 


(IGMP ) 


(IGMP ) 


July 1986 


is used between IP 


hosts and their immediate neighbor multicast agents to support the 


creation of transient groups, 
and the periodic confirmation of group membership. 


a group, 
an asymmetric protocol and is specified here from the point of view 


of a host, 


Like ICMP, 


multicasting specification. 


datagrams, 


rather than a multicast agent. 


IGMP is a integral part of IP. 
implemented in full by all hosts conforming to level 2 of the IP 


with an IP protocol number of 2. 
the following format: 


the addition and deletion of members of 


IGMP is 


It is required to be 


IGMP messages are encapsulated in IP 


All IGMP messages have 


0 1 2 3 
O22 E E E R e E 829-0 As 253 24S 6 7 898 Od E E E Oh 8 OE 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Code | Checksum 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Group Address | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+ Access Key + 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type 
There are eight types of IGMP message: 

1 = Create Group Request 

2 = Create Group Reply 

3 = Join Group Request 

4 = Join Group Reply 

5 = Leave Group Request 

6 = Leave Group Reply 

7 = Confirm Group Request 

8 = Confirm Group Reply 

Deering [Page 13] 


RFC 988 July 1986 
Host Extensions for IP Multicasting 
Code 


In a Create Group Request message, the code field indicates if the 
new host group is to be public or private: 


0 = public 
1 private 


In all other Request messages, the code field contains zero. 


In a Reply message, the Code field specifies the outcome of the 


request: 
0 = request granted 
1 = request denied, no resources 
2 = request denied, invalid code 
3 = request denied, invalid group address 
4 = request denied, invalid access key 
5 - 255 = request pending, retry in this many seconds 
Checksum 


The checksum is the 16-bit one’s complement of the one’s 
complement sum of the IGMP message starting with the IGMP Type. 
For computing the checksum, the checksum field should be zero. 


Identifier 


In a Confirm Group Request message, the identifier field contains 
zero. 


In all other Request messages, the identifier field contains a 
value to distinguish the request from other requests by the same 
host. 


In a Reply message, the identifier field contains the same value 
as in the corresponding Request message. 
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Group Address 


In a Create Group Request message, the group address field 
contains zero. 


In all other Request messages, the group address field contains a 
host group address. 


In a Create Group Reply message, the group address field contains 
either a newly allocated host group address (if the request is 
granted) or zero (if denied). 


In all other Reply messages, the group address field contains the 
same host group address as in the corresponding Request message. 


Access Key 


In a Create Group Request message, the access key field contains 
zero. 


In all other Request messages, the access key field contains the 
access key assigned to the host group identified in the Group 
Address field (zero for public groups). 


In a Create Group Reply message, the access key field contains 
either a non-zero 64-bit number (if the request for a private 
group is granted) or zero. 


In all other Reply messages, the access key field contains the 
same access key as in the corresponding Request. 
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Protocol Rules 


Request messages are sent only by hosts. Reply messages are sent 
only by multicast agents. If a host receives an IGMP message of a 
type other than the four Reply types specified above, the message 
is discarded. 


A Request message is sent with its IP destination field containing 
the well-known address of the Multicast Agent Group. The IP 
time-to-live field is initialized by the sender to 1, in order to 
limit the scope of the request to immediate neighbor multicast 
agents only. The IP source address field contains the individual 
IP address of the sending host. 


A Reply message is sent only in response to a Request message. 

Its IP destination address field contains the individual address 
of the host that sent the corresponding Request. (A Confirm Group 
Reply may also be sent to the host group address specified in its 
corresponding Confirm Group Request.) The IP source address field 
contains the individual IP address of the replying multicast 
agent. 


When a host sends a new Create Group, Join Group, or Leave Group 
Request message, it supplies an arbitrary identifier that it has 
not used within the last TO seconds. (It is usually sufficient 
just to increment the identifier for each new request.) The host 
initializes a timer to Tl seconds and a retransmission counter to 
zero. If a Reply message with a matching identifier is not 
received before the timer expires, it is reset to Tl seconds and 
the retransmission counter is incremented. If the counter is less 
than N1, the host retransmits the Request message with the same 
identifier. If the counter equals N1, the host gives up; if the 
request was to create or join a group, it is deemed to have 
failed; if the request was to leave a group, it is deemed to have 
succeeded. 


If a "request pending" code is received in a matching reply to a 
Create Group, Join Group, or Leave Group Request, the timer is 
reset to the number of seconds specified by the code and the 
retransmission counter is reset to zero. The new timer value 
applies to one timeout interval only -- if the timer expires, it 
is reset to T1 seconds, the counter is incremented, and the 
request is retransmitted. 


The first matching Reply to a Create Group, Join Group, or Leave 
Group Request containing a "request granted" or "request denied" 
code determines the outcome of the request. Any subsequent or 
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non-matching Replies are discarded by the host. However, if a 
host receives an affirmative Create Group Reply or Join Group 
Reply that neither matches an outstanding Request nor contains the 
address of a group to which the host belongs, the host should 
immediately send a Leave Group Request for the unexpected group 
address. 


A "request granted" reply to a Create Group Request implies that, 
as well as the group being created, the requesting host is granted 
membership in the group, i.e. there is no need to send a separate 
Join Group Request. 


Confirm Group Request messages must be sent periodically by hosts 
to inform the neighboring multicast agent(s) of the hosts’ 
continuing membership in the specified groups. If an agent does 
not receive a Confirm Group Request message for a particular group 
within an agent-defined interval, it stops delivering datagrams 
destined to that group. 


For each group to which it belongs, a host maintains a 
confirmation timer and a variable t. The variable t is 
initialized to T2 seconds. Whenever the host’s request to create 
or join a group is granted, and whenever the host either sends a 
Confirm Group Request or receives a Confirm Group Reply with a 
"request granted" code for the group, the host sets the group’s 
timer to a random number uniformly distributed between t and t + 
T3 seconds. If the host receives a a Confirm Group Reply with a 
"request pending" code, t is changed to the value of the code and 
the timer is reset to a random number between the new t and t + 
T3. The variable t retains its value until another "request 
pending" code is received. Whenever the timer expires, the host 
sends a Confirm Group Request. 


Even if a host fails to receive Confirm Group Replies to its 
Requests, it continues to consider itself a member of the group, 
because it may still be able to receive multicast datagrams from 
other hosts on the same local network. Only if a host receives a 
"request denied" code in a Confirm Group Reply does it stop 
sending Confirm Group Requests and consider its membership to be 
revoked. 


Multicast agents respond to Confirm Group Request messages by 
sending Confirm Group Reply messages either to the individual 
sender of the Request or to the host group address specified in 
the Request. By sending back a Confirm Group Reply to all 
neighboring members of a group, a multicast agent is able to reset 
every member’s timer with a single packet. The randomization of 
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the timers is intended to cause only the one member whose timer 
expires first to send a Confirm Group Request, stimulating a Reply 
to reset all the timers. The use of the "request pending" codes 
allows the multicast agent to control the rate at which it 
receives Confirm Group Requests. 


Protocol Timing Constants 


The following timing constants are specified for IGMP. They are 
subject to change as a result of operational experience. 


TO = 300 seconds minimum recycle time for identifiers 

T1 = 2 seconds retrans. interval for Create/Join/Leave Requests 
N1 = 5 tries retrans. limit for Create/Join/Leave Requests 

T2 = 15 seconds initial value for Confirm Request variable t 

T3 = 15 seconds random range for Confirm Request variable t 
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APPENDIX II. HOST GROUP ADDRESS ISSUES 


This appendix is not part of the IP multicasting specification, but 
provides background discussion of several issues related to IP host 
group addresses. 


Group Address Binding 


The binding of IP host group addresses to physical hosts may be 
considered a generalization of the binding of IP unicast 
addresses. An IP unicast address is statically bound to a single 
local network interface on a single IP network. An IP host group 
address is dynamically bound to a set of local network interfaces 
on a set of IP networks. 


It is important to understand that an IP host group address is NOT 
bound to a set of IP unicast addresses. The multicast agents do 
not need to maintain a list of individual members of each host 
group. For example, a multicast agent attached to an Ethernet 
need associate only a single Ethernet multicast address with each 
host group having local members, rather than a list of the 
members’ individual IP or Ethernet addresses. 


Group Addresses as Logical Addresses 


Host group addresses have been defined specifically for use in the 
destination address field of multicast IP datagrams. However, the 
fact that group addresses are location-independent (they are not 
statically bound to a single network interface) suggests possible 
uses as more general "logical addresses", both in the source as 
well as the destination address field of datagrams. For example, 
a mobile IP host might have a host group address as its only 
identity, used as the source of datagrams it sends. Whenever the 
mobile host moved from one network to another, it would join its 
own group on the new network and depart from the group on the old 
network. Other hosts communicating with the mobile one would deal 
only with the group address and would be unaware of, and 
unaffected by, the changing network location of the mobile host. 


Host group addresses cannot, however, be used to solve all 
problems of internetwork logical addressing, such as delivery to 
the "nearest" or the "least loaded" network interface of a 
multi-homed host. Furthermore, there are hazards in using group 
addresses in the source address field of datagrams when the group 
actually contains more than one host. For instance, the IP 
datagram reassembly algorithm relies on every host using a 
different source address. Also, errors in a datagram sent with a 
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group source address may result in error reports being returned to 
all members of the group, not just the sender. In view of these 
hazards, this memo specifies the use of host group addresses only 
as destinations of datagrams, either in the destination address 
field or as the last element of a source routing option. However, 
it is recommended that datagrams with a group source address be 
accepted without complaint, thereby allowing other implementations 
to experiment with logical addressing applications of host group 
addresses. 


Recycling of Transient Host Group Addresses 


Since host group addresses are of fixed, relatively small size, 
transient group addresses must be recycled to satisfy continuing 
requests for creation of new groups. The multicast agents make an 
effort to ensure that a group has no members anywhere in the 
internet before allocating its address to a new group. However, 
under certain conditions of internetwork partitioning and 
membership migration, it is impossible to guarantee unique 
allocation of an address without seriously compromising the 
availability and robustness of host groups. Furthermore, hosts 
that are unaware that a particular group has ceased to exist may 
send datagrams to it long after its address has been assigned to a 
new group. Therefore, hosts should be prepared for the 
possibility of misdelivery of multicast IP datagrams to unintended 
hosts, even in private groups. Such misdelivery can only be 
detected at a level above IP, using higher-level identifiers or 
authentication tokens. (The access key of a private group might 
be used in some applications as such an identifier.) Of course, 
there are other threats to privacy of communication in the 
internet, besides group address collision, such as untrustworthy 
gateways or unsecured networks. End-to-end encryption is an 
effective defense against such threats. 
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